Guidelines: Important Decisions in Requirements

Topics

• Decide How to Perform the Workflow
• Decide How to Use Artifacts
• Decide Which Reports to Use
• Decide How to Maintain "Input Requirements"
• Decide How to Approve Use Cases

Decide How to Perform the Workflow

The following decisions should be made regarding the Requirements workflow:

• Decide how to perform the workflow by looking at the Requirements: Workflow Details. Study the diagram with its guard conditions. Decide which workflow details to perform and in which order. 
• Decide which parts of the requirements workflow to perform. The following are some parts that can be introduced relatively independently of each other.

• Decide when, during the project lifecycle, to introduce each part of the workflow. As a general rule the requirements workflow should be introduce early in the project. 

Document the decisions in the section "Core Workflows / Requirements / Workflow", in the Development Case.  

Decide How to Use Artifacts

Decide which artifacts to use and how to use each of them. The table below describes those artifacts you must have and those used in some cases. For more detailed information on how to tailor each artifact, and a discussion of the advantages and disadvantages of that specific artifact, read the section titled "Tailoring" for each artifact.

For each artifact, decide how the artifact should be used: Must have, Should have, Could have or Won't have. For more details, see Guidelines: Classifying Artifacts.

For each requirements artifact, decide on the types of requirements they contain, the attributes that you'll collect for each, and what traceability will be maintained between them.

Tailor each artifact by performing the steps described in the Activity: Develop Development Case, under the heading "Tailor Artifacts per Workflow".

Decide Which Reports to Use

Decide which reports to use. As a starting point, use the following reports:

• Report: Use-Case
• Report: Use-Case Model Survey
• Report: Use-Case Storyboard
• Report: Actor
• Report: Class

See Report Overview for more details.

Decide How to Maintain Input Requirements

This section only applies if a formal contract, standard or specification document is imposing requirements to the requirements management effort. It is referred to as the "input requirements specification".

During the requirements effort, you capture the requirements in a Vision document, in Stakeholder Requests, in a use-case model, and in Supplementary Specifications.

Decide whether the input requirements specification will be maintained or not. Will you go back and update the input requirements specification when you discover a requirement was bad, wrong or faulty? You must also decide how traces or references between the input requirement specification and the use cases will be maintained.

Choose one, or a combination of, the following strategies:

• Do not update the input requirement specification. Let the use cases and the Supplementary Specification specify what the system will do hereafter.
• Do not update the input requirements specification, but maintain the traceability from use cases back to it.
• Update the input requirements specification with all work and costs involved.
• Let the input requirements specification evolve into a Supplementary Specification containing non-functional requirements. The functional input requirements are simply transferred to the use cases.

Most projects find that the number of requirements which are bad, faulty or wrong is so large, it doesn't make sense to maintain the original input requirements specification. Very few projects have customers willing to pay for the work of updating the input requirements specification with the new information revealed during use-case modeling.

Don't stress this topic too early. In the beginning of a project, people still believe in the initial requirements specification, however, after working through the problem area with a use case, most people have quite a different view of the initial requirements specification.

Decide How to Approve Use Cases

Decide how to approve the use cases. A lot of time can be saved by limiting the number of use cases that have to be formally reviewed by the customer. Perhaps it's acceptable for the customer to formally review only a subset of all use cases.

Choose one or more of the following strategies:

• All use cases must pass formal external reviews with representatives who are external to the project.
• Some secondary use cases can be approved in a simplified way, at either an informal or an internal formal review.

Secondary use cases are those use cases essential to the system but not to the task of the primary user; for example, use cases related to the administration and maintenance of the system, such as adding users to the system, changing their authority, and making backups. The system will not work without these use cases, although they're not of primary interest to the important users.

The strategy you use depends on your relationship with your customer. Do they trust that you can do the supporting use cases correctly without a formal approval process? Although this would save a considerable amount of time, will you reach the right quality of the use-case model?

Note: A solution to the problem may involve the customer in the Requirements effort. By involving customer representatives, they will be able to approve or give recommendations to other customers, and by involving the customer, the project gains credibility.

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Rational Unified Process